perm filename BREAK.BUG[LSP,SYS] blob sn#049042 filedate 1973-06-17 generic text, type T, neo UTF8
 
∂17-JUN-73  1433		FOO,DBA
 Don't know when you will get this - more details on the BREAK problem.
 It seems to be connected with interrupting (GO foo) statements. In this
 case the OK or GO does not reset the break depth counter,and the break
 is not properly released.  The next interrupt of GO gives a depth of
 one more, but doing ↑ causes one of two kinds of lossage:
 1.  xxxxxxx ILL MEM REF FROM UNBREAK0
     (/BREAK1 BROKEN)
 in which case the only escape is ↑↑ (which continues to work)
 2.  xxxxxxx ILL MEM REF FROM SETARG
     NON-NUMERIC ARGUMENT
 at which time the thing goes into a tight loop from which ther
 is no escape.
 If you don't tell me you have got this message soon, I'll try
 Daryle Lewis at BBN.
 In case anyone else reads this, the problem is as follows: funnies
 when interrupting
 (PROG NIL LBL (PRINC @FOO)(GO LBL))
 If the (GO LBL) is interrupted then on doing OK or GO and another
 interrupt, the second break thinks it is at a depth of 2. Now read
 top of message down!